home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000046_icon-group-sender _Mon Jun 1 09:05:41 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id JAA02642
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 1 Jun 1998 09:05:35 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA04735; Mon, 1 Jun 1998 09:05:28 -0700
  7. Message-Id: <3.0.5.32.19980530023718.007aa100@doors>
  8. X-Sender: bgbauer#alpha.delta.edu@doors
  9. X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
  10. Date: Sat, 30 May 1998 02:37:18 -0700
  11. To: "Icon Group"<icon-group@optima.CS.Arizona.EDU>
  12. From: bauerb <bauerb@geocities.com>
  13. Subject: Re: Determining O/S
  14. Mime-Version: 1.0
  15. Content-Type: text/plain; charset="us-ascii"
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 3679
  19.  
  20.  
  21.    >At 05:56 AM 5/27/98 -0500, GEP wrote:
  22.    >>Note that under Windows (of any flavor) the program can be changed from 
  23.    >>"console" to "windowed" at any time, and vice-versa, and without advance
  24.    >>notice.
  25.  
  26. >>   How?  Isnt the program limited to console only, if compiled with NTICONT?
  27. >>   and Windowed only, if compiled with WICONT?
  28.  
  29. >As near as I can tell, you are right.  I don't know what he means here.
  30.  
  31. >Clint, jeffery@cs.utsa.edu
  32.  
  33.  
  34. Ok, I guess the easiest way for me to explain, is give a few examples.
  35.  
  36. I've created a procedure DateInFormat(i, s1):s2
  37.  
  38. i     an integer of the seconds past the standard 'base year' of 1970.
  39. (optional,       default is current time).
  40. s1    a string template for the Date.  Example: "dddd, MMMM dd, yyyy"
  41.       or "MM/dd/yy".  (optional, default is the users current preference, 
  42.       as determined using 'localization' settings for windows.
  43. s2    a string of the date in the format of s1.  Examples: (using above
  44. templates)
  45.       "Tuesday, March 10, 1987" or "3/10/87"
  46.  
  47. So I can do something similar to 
  48.  
  49. sdate := DateInFormat(secs)
  50.  
  51. and have the date formatted in the standard the user is used to, or if I
  52. specify
  53. a format, in that format (which could even be something like
  54. DateInFormat(,"Today is dddd") : "Today is Tuesday".
  55.  
  56. Ok, in this situation, the localization (and timezone bias etc.) settings
  57. for win3.1 are located in win.ini, but the localization settings for win95
  58. and NT are located in
  59. the registry.   In win95 they are 'left' in the win.ini, but arent
  60. maintained, so daylight savings time isnt accounted for, and neither are
  61. changes to timezones after the user first installs Win95.  (In my
  62. situation, Ive moved from -5 to -8 hoursfromGMT since installing win95,
  63. which means at times the win.ini settings for timezone are up to 4 hours
  64. incorrect.)   So this is why It would matter if Im in Win3.1 or Win95/NT.
  65. The procedure would need to gather 'defaults' from separate places
  66. depending on what O/S it's run on (and yet another location from UNIX if
  67. one exists).
  68.  
  69. I realise I can use system("VER > VER.TMP") but so far I've had trouble
  70. with system() commands which create new files (as was talked about in
  71. previous posts).  Im just wondering the 'fastest' and 'least overhead' way
  72. to determine O/S.
  73.  
  74. Win3.1/Win32's cant count the same as Win95 in this case, so the &features
  75. way Ive noticed people use I don't think will work.
  76.  
  77.  
  78.  
  79. About the "console" or "window":
  80.  
  81. The main program I am working on now, I originally coded all to work as a
  82. DOS Command line utility.  Im ready now, to take the source, and begin
  83. adding windows features, and compile using wincont.
  84.  
  85. I would like to not have to maintain 2 separate versions of source, and
  86. separately compiled executables, just to offer 2 different versions of the
  87. program. 1 for DOS, one for Windows.
  88.  
  89. Im wondering if its possible to do something similar to:
  90.  
  91. If \win then WindowWrite("My output")  # run as a windows app
  92. else write("My output")                # run as console app
  93.  
  94. (Forgive me but I cant remember the function to write to a window yet.)
  95.  
  96. >From testing, ive noticed I will now need to go through all my source, and
  97. alter
  98. any of the commands I used to give status reports, changing them from
  99. 'write()'
  100. to the correct "Windows" command, otherwise programs compiled with WICONT
  101. seem to create a new window just for write() output.  But if I change them
  102. all, I lose the ability to run the app in DOS mode.  So i'll have to
  103. maintain two separate versions.
  104.  
  105. Is there a way to run a program compiled with wicont, as a console app? and
  106. keeps its
  107. output to the console, and not a window?
  108.  
  109. Hopefully I havent confused you more, I appologise if I have.
  110.  
  111. scissors
  112.  
  113.  
  114.  
  115.